home *** CD-ROM | disk | FTP | other *** search
/ Halting the Hacker - A P…uide to Computer Security / Halting the Hacker - A Practical Guide to Computer Security.iso / rfc / rfc1455.txt < prev    next >
Text File  |  1997-04-01  |  12KB  |  339 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                   D. Eastlake, III
  8. Request for Comments: 1455                 Digital Equipment Corporation
  9.                                                                 May 1993
  10.  
  11.  
  12.                  Physical Link Security Type of Service
  13.  
  14. Status of this Memo
  15.  
  16.    This memo defines an Experimental Protocol for the Internet
  17.    community.  Discussion and suggestions for improvement are requested.
  18.    Please refer to the current edition of the "IAB Official Protocol
  19.    Standards" for the standardization state and status of this protocol.
  20.    Distribution of this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    This RFC documents an experimental protocol providing a Type of
  25.    Service (TOS) to request maximum physical link security.  This is an
  26.    addition to the types of service enumerated in RFC 1349: Type of
  27.    Service in the Internet Protocol Suite.  The new TOS requests the
  28.    network to provide what protection it can against surreptitious
  29.    observation by outside agents of traffic so labeled.  The purpose is
  30.    protection against traffic analysis and as an additional possible
  31.    level of data confidentiality.  This TOS is consistent with all other
  32.    defined types of service for IP version 4 in that it is based on link
  33.    level characteristics and will not provide any particular guaranteed
  34.    level of service.
  35.  
  36. 1. Nature of Requirement
  37.  
  38.    This Internet Protocol addition addresses two potential security
  39.    requirements: resistance to traffic analysis and confidentiality.
  40.    These are described in the two subsections below followed by a
  41.    discussion of why links have different levels of physical security so
  42.    that it is meaningful to request that more secure links be used.
  43.  
  44. 1.1 Traffic Analysis
  45.  
  46.    At this time all Internet Protocol (IP) packets must have most of
  47.    their header information, including the "from" and "to" addresses, in
  48.    the clear.  This is required for routers to properly handle the
  49.    traffic even if a higher level protocol fully encrypts all bytes in
  50.    the packet after the IP header.  This renders even end-to-end
  51.    encrypted IP packets subject to traffic analysis if the data stream
  52.    can be observed.  While traffic statistics are normally less
  53.    sensitive than the data content of packets, in some cases activities
  54.    of hosts or users are deducible from traffic information.
  55.  
  56.  
  57.  
  58. Eastlake                                                        [Page 1]
  59.  
  60. RFC 1455                   Link Security TOS                    May 1993
  61.  
  62.  
  63.    It is essential that routers have access to header information, so it
  64.    is hard to protect traffic statistics from an adversary with inside
  65.    access to the network.  However, use of more secure physical links
  66.    will make traffic observation by entities outside of the network more
  67.    difficult thus improving protection from traffic analysis.
  68.  
  69.    No doubt users would like to be able to request a guaranteed level of
  70.    link security, just as they would like to be able to request a
  71.    guaranteed bandwidth or delay through the network.  However, such
  72.    guarantees require a resource reservation and/or policy routing
  73.    scheme and are beyond the scope of the current IP Type of Service
  74.    facility.
  75.  
  76.    Although the TOS field is provided in all current Internet packets
  77.    and routing based on TOS is provided in routing protocols such as
  78.    OSPF [See 5,6,7], there is no realistic chance that all of the
  79.    Internet will implement this additional TOS any time in the
  80.    foreseeable future.  Nevertheless, users concerned about traffic
  81.    analysis need to be able to request that the physical security of the
  82.    links over which their packets will be pass be maximized in
  83.    preference to other link characteristics.  The proposed TOS provides
  84.    this capability.
  85.  
  86. 1.2 Confidentiality
  87.  
  88.    Use of physical links with greater physical security provides a layer
  89.    of protection for the confidentiality of the data in the packets as
  90.    well as traffic analysis protection.  If the content of the packets
  91.    are otherwise protected by end-to-end encryption, using secure links
  92.    makes it harder for an external adversary to obtain the encrypted
  93.    data to attack.  If the content of the packets is unencrypted plain
  94.    text, secure links may provide the only protection of data
  95.    confidentiality.
  96.  
  97.    There are cases where end-to-end encryption can not be used.
  98.    Examples include paths which incorporate links within nations which
  99.    restrict encryption, such as France or Australia, and paths which
  100.    incorporate an amateur radio link, where encryption is prohibited.
  101.    In these cases, link security is generally the only type of
  102.    confidentiality available.  The proposed TOS will provide a way of
  103.    requesting the best that the network can do for the security of such
  104.    unencrypted data.
  105.  
  106.    This TOS is required for improved confidentiality, especially in
  107.    cases where encryption can not be used, despite the fact that it does
  108.    not provide the guarantees that many users would like.  See
  109.    discussion at the end of the Traffic Analysis section above.
  110.  
  111.  
  112.  
  113.  
  114. Eastlake                                                        [Page 2]
  115.  
  116. RFC 1455                   Link Security TOS                    May 1993
  117.  
  118.  
  119. 1.3 Link Physical Security Characteristics
  120.  
  121.    Physical links, which are composed of lines and routers, differ
  122.    widely in their susceptibility to surreptitious observation of the
  123.    information flowing over them.  For examples of line security see the
  124.    following list:
  125.  
  126.       1) Land line media is usually harder to intercept than radio
  127.          broadcast media.
  128.  
  129.       2) Between different radio broadcast media, spread spectrum or
  130.          other low probability of intercept systems, are harder to
  131.          intercept than normal broadcast systems.  At the other extreme,
  132.          systems with a large footprint on the earth, such as some
  133.          satellite down links, may be particularly accessible.
  134.  
  135.       3) Between land lines, point to point systems are generally harder
  136.          to intercept than multi-point systems such as Ethernet or FDDI.
  137.  
  138.       4) Fiber optic land lines are generally harder to intercept than
  139.          metallic paths because fiber is harder to tap.
  140.  
  141.       5) A secure land line, such as one in pressurized conduit with
  142.          pressure alarms or one installed so as to be observable by
  143.          guards, is harder to intercept than an unsecured land line.
  144.  
  145.       6) An encrypted link would be preferable to an unencrypted link
  146.          because, even if it was accessed, it would be much more
  147.          difficult to obtain any useful information.
  148.  
  149.    Routers also have different levels of security against interception
  150.    depending on the physical security of the router site and the like.
  151.  
  152.    The above comparisons show that there are significant real
  153.    differences between the security of the physical links in use in the
  154.    Internet.  Choosing links where it is hard for an outside observer to
  155.    observe the traffic improves confidentiality and protection against
  156.    traffic analysis.
  157.  
  158. 2. Protocol Specification
  159.  
  160.    The value 15 decimal (F hex) in the four-bit Type of Service IP
  161.    header field requests routing the packet to minimize the chance of
  162.    surreptitious observation of its contents by agents external to the
  163.    network.  (This value is chosen to be at the maximum hamming distance
  164.    from the existing other TOS values.)
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Eastlake                                                        [Page 3]
  171.  
  172. RFC 1455                   Link Security TOS                    May 1993
  173.  
  174.  
  175. 3. Protocol Implementation
  176.  
  177.    This TOS can be implemented in routing systems that offer TOS based
  178.    routing (as can be done with OSPF, see RFCs 1245 through 1247) by
  179.    assigning costs to links.  Establishing the "cost" for different
  180.    links for this TOS is a local policy function.
  181.  
  182.    In principle services are incomparable when criterion such as those
  183.    given in the Nature of Requirement section above conflict.  For
  184.    example, a choice between an encrypted broadcast system and an
  185.    unencrypted fiber optic land line.  In practice, link encryption
  186.    would probably dominate all other forms of protection and physical
  187.    security as mentioned in criterion 5 above would dominate other land
  188.    line distinctions.
  189.  
  190.    An example of "costs" at a hypothetical router could be as follows:
  191.  
  192.            Cost    Type
  193.             1      Strong encryption with secure key distribution
  194.             2      Physically secure point-to-point line
  195.             6      Typical point-to-point line
  196.             8      Typical local multi-point media
  197.            12      Metropolitan area multi-point media
  198.            24      Local radio broadcast
  199.            32      Satellite link
  200.  
  201.    Link costs should be chosen so as to be in the same ratio as the
  202.    probability of interception.  Thus the above example costs imply a
  203.    local policy assumption that interception is 32 times more likely on
  204.    a satellite link and associated router than on a strongly encrypted
  205.    line and its associated router.  It is not necessary to estimate the
  206.    absolute probability of interception on any particular link.  It is
  207.    sufficient to estimate the ratio between interception probabilities
  208.    on different links.
  209.  
  210.    It should be noted that using costs such as the example given above
  211.    could result in using many more links than if the default type of
  212.    service were requested.  For example, the use of over 50 highly
  213.    secure links could be better than using two insecure links, such as
  214.    an unencrypted satellite hop and radio link.  However, if the costs
  215.    have been properly set in proportion to the probability of
  216.    interception, this larger number of links will be more secure than
  217.    the shorter default routing.  This consideration should make it clear
  218.    why it is necessary to estimate router security as well as link
  219.    security.  An excessive cost ratio based solely on the security of a
  220.    communications line could cause packets to go through many routers
  221.    which were less secure than the lines in question.  This necessity to
  222.    take router characteristics into account is also present for all
  223.  
  224.  
  225.  
  226. Eastlake                                                        [Page 4]
  227.  
  228. RFC 1455                   Link Security TOS                    May 1993
  229.  
  230.  
  231.    other defined TOS values.
  232.  
  233.    It should also be noted that routing algorithms typically compute the
  234.    sum of the costs of the links.  For this particular type of service,
  235.    the product of the link probabilities of secure transmission would be
  236.    more appropriate.  However, the same problem is present for the high
  237.    reliability TOS and the use of a sum is an adequate approximation for
  238.    most uses as noted in RFC 1349.
  239.  
  240. References
  241.  
  242.    [1] Postel, J., "Internet Protocol - DARPA Internet Program Protocol
  243.        Specification", STD 5, RFC 791, DARPA, September 1981.
  244.  
  245.    [2] Braden, R., Editor, "Requirements for Internet Hosts --
  246.        Communication Layers", STD 3, RFC 1122, IETF, October 1989.
  247.  
  248.    [3] Braden, R., Editor, "Requirements for Internet Hosts --
  249.        Application and Support", STD 3, RFC 1123, IETF, October 1989.
  250.  
  251.    [4] Almquist, P., "Type of Service in the Internet Protocol Suite",
  252.        RFC 1349, Consultant, July 1992.
  253.  
  254.    [5] Moy, J., Editor, "OSPF Protocol Analysis", RFC 1245, Proteon,
  255.        Inc., July 1991.
  256.  
  257.    [6] Moy, J., Editor, "Experience with the OSPF Protocol", RFC 1246,
  258.        Proteon, Inc., July 1991.
  259.  
  260.    [7] Moy, J., "OSPF Version 2", RFC 1247, Proteon, Inc., July 1991.
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Eastlake                                                        [Page 5]
  283.  
  284. RFC 1455                   Link Security TOS                    May 1993
  285.  
  286.  
  287. Security Considerations
  288.  
  289.    The entirety of this memo concerns an Internet Protocol Type of
  290.    Service to request maximum physical link security against
  291.    surreptitious interception.
  292.  
  293. Author's Address
  294.  
  295.    Donald E. Eastlake, III
  296.    Digital Equipment Corporation*
  297.    30 Porter Road, MS: LJO2/I4
  298.    Littleton, MA 01460
  299.  
  300.    Phone: +1 508 486 2358 (w),  +1 617 244 2679 (h)
  301.    Email: dee@ranger.enet.dec.com
  302.  
  303.    *Company affiliation given for identification only.  This document
  304.    does not constitute a statement, official or otherwise, by Digital
  305.    Equipment Corporation.
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Eastlake                                                        [Page 6]
  339.